IP Multimedia (IPMM) services provide a combination of voice, video, messaging, data, etc, within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This leads to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IMS is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enhance the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new enhanced person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
Within an IMS network, Call Session Control Functions (CSCFs) perform processing and routing of signalling. CSCFs handle session establishment, modification and release of IP multimedia sessions using the SIP/SDP protocol suite. 3GPP TS23.228 describes the logical nodes P-CSCF, I-CSCF, S-CSCF, E-CSCF and BGCF. The S-CSCF conforms to 3GPP TS 24.229 and performs session control services for User Equipments (UEs). It maintains the session state to support the services, and performs the following functions:                it acts as a registrar according to [RFC3261] at registration;        it notifies subscribers about registration changes;        it provides session control for the registered users' sessions;        it handles SIP requests, and either services these internally or forwards them on to a further node; and        it interacts with IMS Application Servers.        
The S-CSCF performs SIP routing according to 3GPP routing procedures. For inbound SIP traffic, the S-CSCF will route sessions to that P-CSCF whose address was stored during subscriber registration. For outbound SIP traffic, the S-CSCF interrogates a DNS/ENUM to determine how the call should be routed. The S-CSCF interacts with the Home Subscriber Server (HSS) to obtain subscriber data and to exchange authentication information using DIAMETER messages.
The IMS allows IMS subscribers to initiate sessions with non-IMS users, including users connected to conventional telephone networks. IMS subscribers may also be allocated addresses such as telephone numbers to allow for incoming calls to be made to these subscribers via external networks. This results in increased usage of new multimedia services and therefore higher revenues for operators.
Each UE in an IMS may preferentially use specific Application Servers for executing originating services, terminating services or any other services required in a communication or call session. These preferences are linked to each UE and stored in an Initial Filter Criteria (iFCs) located in the HSS of a user's home network. A user's iFCs are downloaded to the S-CSCF upon registration of the user with the S-CSCF, or upon receiving a particular service demand.
Whenever a user A sends an SIP request, such as an SIP INVITE signal, to the S-CSCF, indicating that it would like to enter a communication session with user agent B, the S-CSCF checks user agent's iFC to determine which Application Server should execute outgoing services for A.
Similarly, user B may always use a particular Application Server to execute terminating services. In particular, an iFC for user B may specify that two distinct Application Servers are to be used for terminating services handled for B, and originating services handled for B, respectively.
In case user B wishes to divert or forward a call it received, two distinct Application Servers may therefore be involved: a first Application Server handling terminating services for a first communication leg terminating at B, and a second Application Server handling originating services for the new communication leg originating at B, and terminating at the new target.
An ISM may also take advantage of legacy services that are available in a network operator's infrastructure. An example of such legacy services are Customized Applications For Mobile Enhanced Logic (CAMEL) services.
In the context of mobile telecommunications networks of the second generation (2G), such as GSM networks, Intelligent Networks (IN) were developed to provide additional, more flexible supplementary subscriber services. Supplementary subscriber services may be divided into two types: firstly, those, which modify or supplement the process of originating a call and secondly, those, which modify or supplement the process of terminating a call. An example of originating supplementary services is the barring of outgoing calls. Examples of terminating supplementary services include barring incoming calls, call forwarding, and call waiting.
The usage of standardised IN elements, which accomplish the deployment of IN services, is specified in the Customized Applications For Mobile Enhanced Logic, (CAMEL) standard. The CAMEL standard forms part of the GSM Network (ETSI) and the 3rd Generation Partnership Project (3GPP) specifications. CAMEL service triggers are defined and accessible by the Mobile Switching Center (MSC) in a GSM network. For example, when the MSC receives a call diversion request from a user and a corresponding CAMEL trigger is defined for the diverting user, the MSC contacts a CAMEL service using a CAMEL Application Part (CAP) request. The CAMEL service then provides the appropriate service for the call, such as call forwarding or diversion, for example.
If a user has subscribed to a CAMEL service, this information will be reflected in a CAMEL Subscription Information (CSI), which is generally stored in the user's HSS. The CSI is retrieved by the CAMEL service when it handles a CAMEL request. As CAMEL services are available for both originating and terminating services, separate profiles for originating (O-CSI) and terminating (T-CSI) may be available for a given user.
In the case of a call diversion or forwarding, the O-CSI of the diverting or forwarding user may also include information on whether CAMEL services should be invoked on the new communication leg, which will link the diverting user to the new target.
In GSM networks, this information is made available to the MSC. As a user will use the same MSC for both terminating and originating services, that MSC will know whether CAMEL services should or should not be invoked on the new communication leg, and it will set up the leg accordingly.
CAMEL services have been implemented by many operators for use in their GSM networks, often involving significant costs. Many operators still use these services in conjunction with their ISM network infrastructure.
For example, in case user B in an ISM network wishes to divert or forward a call it received to a new target, the first Application Server handling terminating services for the first communication leg terminating at B may send a CAP request to a CAMEL service. The CAMEL service will retrieve O-CSI information for at least one of the subscribers involved in the diversion request and send it in a CAP reply to the first Application Server. This O-CSI information may include information as to whether CAMEL services should be used on the new communication leg, or not.
The originating services for user B may be executed by a second Application Server in charge of establishing the new communication leg. However, the O-CSI information that has been retrieved by the first Application Server is not available at the second Application Server. The second Application Server therefore sends a new CAP request to the CAMEL service, which will retrieve the O-CSI information once more. This results in a particular waste of network resources and time if the O-CSI information retrieved by the first Application Service indicated that CAMEL service should not be invoked on the new communication leg.
An example would be if B is provisioned with an originating service such as Number Portability in CAMEL. Number Portability enables a subscriber of a telecommunication provider to port the subscribed service to another telecommunication provider in that country, but retain the telephone number.
A CAMEL service implementation invoked by the first Application Server, handling terminating services for B, would check if the called party number is a ported number. Then there should be no need to check the called party number for Number Portability once again at the second Application Server, which handles originating services for B. In existing IMS architectures using CAMEL services, the second Application Server would however check the called party number for Number Portability one more time, as the corresponding information is not available to it.
According to existing and currently proposed IMS architectures, there is no easy way to configure an Application Server, CAMEL service or CSCF so as to address this unwanted behaviour.